Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES

--000e0cd2c0526d39e1046a86a8ea
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Fri, May 22, 2009 at 4:21 PM, Jeff Trawick wrote:

>
>
> On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr. > > wrote:
>
>> Joe Orton wrote:
>> >
>> > Having thought about this longer, I do agree that it would be reasonable
>> > to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it
>> > turns out we're out of bits - allow_options_t is an unsigned char and
>> > we're using 2^0 through 2^7 already. :(
>>
>> The C langauge promotes char -> int for comparison. 256 should work fine,
>> no? It would devolve to 0, of course, but 256 & 255 should test fine.
>>
>> Thoughts?
>
>
> Backing up a bit...
>
> I originally thought we could map bit values in 2.2.x to avoid affecting
> modules, but that isn't possible since includes-with-exec is two bits
> instead of one.
>
> Mapping OPT_INCNOEXEC to a no-op integer is something that takes place at
> compile time, and helps applications which reference the symbol but don't
> use it in any important way. (IOW, let mod_perl and other similar tarballs
> compile.) It is good in that it lets mod_perl compile, but bad in that
> mod_perl continues to export the Perl mapping of OPT_INCNOEXEC even after
> httpd has been upgraded and at some point later mod_perl is upgraded.
>
> Failing the compile is our only opportunity to catch some affected modules
> (though it is a rather late opportunity since the modules will likely be
> rebuilt later since they're supposed to work as-is when upgrading httpd;
> somebody will grumble though).
>
> I don't think we should try to preserve compilability if we can't preserve
> compatibility.
>
>
>>
>> > The only available option is to #define OPT_INCNOEXEC to some bogus
>> > string or something; not sure I like that much better than just a clean
>> > break.
>>
>
> /*
> * #define OPT_INCNOEXEC 32
> * Apache 2.2.12 and later no longer provide this.
> * Applications which distinguish between includes-without-exec and
> includes-with-exec
> * must use different logic for 2.2.<12 and 2.2.>=12.
> * Prior to 2.2.12:
> * includes-without-exec: OPT_INCNOEXEC flag on, OPT_INCLUDES flag off
>

oops, both flags were on here


>
> * includes-with-exec: OPT_INCNOEXEC flag off, OPT_INCLUDES flag on
> * As of 2.2.12:
> * includes-without-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag
> off
> * includes-with-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag on
> *
> */
>

--000e0cd2c0526d39e1046a86a8ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable